All DatabasesMacTech Vol 10-1994
Client-Server
Volume Number: 10
Issue Number: 3
Column Tag: From The Trenches
True Life Story
Developing a Client-Server system
By Malcolm H. Teas, Rye, New Hampshire
Note: Source code files accompanying article are located on MacTech CD-ROM or
source code disks.
About the author
Malcolm Teas has been programming the Macintosh for five years in C with MPW
and Think C. He’s active with object programming in TCL because he has a short
attention span and likes to write applications quickly. His most recent shareware is
Apple π, a π calculation program available on America Online. He lives, works, and
consults from his house on the seacoast of New Hampshire. Seacoast Software, 556
Long John Road, Rye, NH 03870-2213, mhteas@aol.com or mhteas@well.sf.ca.us
In the spirit of all those TV shows with “real-life” themes, and temporarily
short of real article ideas, I proposed an article on the true-to-life story of how I
recently helped develop a client-server system. They probably accepted this article
because I used the words “Case History” in my proposed title, which sounds like I’m
knowledgeable. Of course I might have just caught them on an good day.
In any case, the plot for this story takes two programmers (including myself)
and pits them against the clock and programming bugs to implement a system that the
customer needed for a legal deadline. Our customer decided that, while it’d be alright if
I wrote about this, they didn’t want their name and business included, therefore,
they’ll remain “our customer” to preserve their competitive secret. Their business,
of course, should never be associated with air conditioning equipment. You never heard
it from me.
What the customer needed
Our customer must, by law, track the intelligent use of their product by their
large customers. To do this, there are customer representatives that visit their
customers, survey them, then file papers on the surveys. For various reasons these
surveys may be audited periodically, so, unlike the rest of us, they must actually be
able to find the papers they’ve filed over the last several years.
Our customer had been doing this for some time, not completely successfully,
with paper, filing cabinets, and lots of clerks. The Macintoshes were used to generate
paper and keep the clerks busy. Although the Macs were connected in a large network,
they weren’t taken advantage of for this sort of purpose. Pages were printed on a laser
printer, photocopied, then one copy was filed locally and the other was US-mailed to an
archiving office.
The problems with this system were substantial. To start with, it was slow.
Papers often became misfiled, were on someone’s desk for audit work and so
unavailable to others, or got lost in the mail. The US Mail costs were starting to get
expensive. It was difficult to analyze the reports in another order from the original
filing order. In short, the existing system was unwieldy.
Our Client-Server design
The management that brought us in wanted to use the Macintosh more fully. The
customer was using MS-Mail and file servers throughout the company successfully and
was interested in making better use of the Macs and their network with a
“network-enabled application” or “netware” as they called it. They saw this project
as a way to move toward that.
We came up with a client-server system that uses a 4D database as the server
application, and a client application written in Think C. Documents are archived by
dragging their icons onto the client application icon. The client app starts up, allows
the user to specify the archiving criteria, sends the document to the server, and quits.
Since far fewer people need to retrieve documents than need to archive them, we
used simple file sharing on the server to allow people to retrieve documents. The
client front-end application allows a wider range of less technically sophisticated
people to archive documents correctly. A user doesn’t need file sharing privileges to
archive a document. Later, in release two, we changed this because the number of
users was expected to grow substantially.
The client application has one window with popups on the left side to specify the
state, division, and year that the document should be filed under. On the right side of
the window are two scrolling lists: the customer’s name and number; and the
customer’s location. The customer’s name list contents is determined by the criteria
on the left side. The contents of the customer’s location list is determined by the left
side criteria and the selected customer.
There are fields that show the currently selected customer and location. Some
checkboxes allow new customer’s names, numbers, and locations to be added. This
addition takes place when the document is actually filed. The document is filed when
the “Archive” button in the lower right of the window is clicked.
These are the essential elements of the client application. It has no menu bar.
The application is basically a one-shot. The window (in the first version) is actually a
dialog.
What’s done where
We found that the main design issue was how to divide the functionality between
the client and server applications. We had to decide this first; the system design was
too unwieldy otherwise. Once determined, the messages between the two were defined
and each piece became modularized.
Our server is a simple one that receives, stores, and retrieves data for the client.
A client-server architecture is good for sharing common data with more than one user.
The server handles the common part and the client creates the interface to it. We
needed the server to store the documents and the criteria (customer information,
state, division, etc.) used to index them.
User interaction and interface, on the other hand, is best handled on the client.
After all, a program with one user is faster than a program with multiple users. This,
ultimately, is the reason behind moving from mainframe-centered systems to
client-server systems. Although speed isn’t always an issue in the user interface
(after all, humans can take a long time - up to several hundred milliseconds - to
recognize that something changed on the screen, much less understand it), we can use
the processing time to format and display the data in useful ways for the user. The
client application also tries to “condition” the data sent to the server so the server
Referenced by (12):